home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Nov 89 / 0018-Re Casting-Nov89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.7 KB  |  62 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    3046572                         2-Nov-89        18:20
  4.  
  5. From:   ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. To:     D1282                           Power Up,PRT
  8.  
  9. cc:     MACAPP.TECH$                    MacApp Technical
  10.  
  11. Sub:    re Casting
  12.  
  13. I would make 2 minor comments about your message on object casting.
  14.  
  15. (1) You are right that casting an object primarily affects the compiler's view
  16. of the object.  This is 100% true in a non-debug version of the program.  When
  17. debugging is turned on, then an object cast generates a run time check to
  18. ensure that the cast is valid.
  19.  
  20.  
  21. (2) If I were implementing a TShapeList class, I wouldn't make it a subclass of
  22. TSortedList.  I would use a TSortedList as a field in the object.
  23.  
  24. In TShapeList, I would then define the exact interface that I wanted my clients
  25. to use.  That interface could deal with TShape objects, which means that
  26. clients wouldn't have to do any casting.  All the casts would be inside the
  27. implementation of TShapeList.
  28.  
  29. (Another advantage is that the same class could handle different sorting
  30. functions, simply by initializing TShapeList with different instances of
  31. TSortedList.)
  32.  
  33. Most of the operations defined on TShapeList would call similar methods of
  34. TSortedList.  This adds a bit of run-time overhead, but it isn't very
  35. significant.  (I've actually implemented a TShapeList class using this
  36. technique, although I used TList instead of TSortedList.  In C++, you could
  37. make the method of TShapeList inline, and there wouldn't be any overhead at
  38. all.)
  39.  
  40. The reason I suggest this implementation is that TShapeList isn't really a kind
  41. of TSortedList.  TShapeList is a brand new type, unrelated to TSortedList.  You
  42. do want to reuse the code from TSortedList, however, which is why you use an
  43. instance of TSortedList as a field of TShapeList.
  44.  
  45. In other languages, you can do this in a more straightforward way.  For
  46. example, in C++ you could make TSortedList a private base class of TShapeList.
  47. TShapeList inherits the code of TSortedList, but doesn't make the TSortedList
  48. interfaces public.  Then you can publicize the operations of TSortedList that
  49. you want TShapeList to have.  This doesn't solve the casting problems, however.
  50.  
  51. To solve the casting problems, you would need a feature called parameterized
  52. types, which C++ will someday support.  With this feature, one could define a
  53. type TSortedList<T>, where T is a type.  To use this class, you need to supply
  54. a value for T.
  55.  
  56. TShapeList would then be defined as TSortedList<TShape>.  The resulting class
  57. is completely type-safe (all the methods deal with TShape objects), but uses
  58. the same code as TSortedList.
  59.  
  60. Larry Rosenstein
  61.  
  62.